How to Sync with Alice

This paper explains the sync problem and compares solutions in Firefox 4 and Chrome 10. The sync problem studies how to securely synchronize data across different computers. Google has added a built-in sync function in Chrome 10, which uses a user-defined password to encrypt bookmarks, history, cached passwords etc. However, due to the low-entropy of passwords, the encryption is inherently weak -anyone with access to the ciphertext can easily uncover the key (and hence disclose the plaintext). Mozilla used to have a very similar sync solution in Firefox 3.5, but since Firefox 4 it has made a complete change of how sync works in the browser. The new solution is based on a security protocol called J-PAKE, which is a balanced Password Authenticated Key Exchange (PAKE) protocol. To our best knowledge, this is the first large-scale deployment of the PAKE technology. Since PAKE does not require a PKI, it has compelling advantages than PKI-based schemes such as SSL/TLS in many applications. However, in the past decade, deploying PAKE has been greatly hampered by the patent and other issues. With the rise of patent-free solutions such as J-PAKE and also that the EKE patent will soon expire in October, 2011, we believe the PAKE technology will be more widely adopted in the near future. © 2011 Newcastle University. Printed and published by Newcastle University, Computing Science, Claremont Tower, Claremont Road, Newcastle upon Tyne, NE1 7RU, England. Bibliographical details HAO, F., RYAN, P.Y.A. How to Sync with Alice [By] F. Hao, P. Y. A. Ryan Newcastle upon Tyne: Newcastle University: Computing Science, 2011. (Newcastle University, Computing Science, Technical Report Series, No. CS-TR-1260) Added entries NEWCASTLE UNIVERSITY Computing Science. Technical Report Series. CS-TR-1260 Abstract This paper explains the sync problem and compares solutions in Firefox 4 and Chrome 10. The sync problem studies how to securely synchronize data across different computers. Google has added a built-in sync function in Chrome 10, which uses a user-defined password to encrypt bookmarks, history, cached passwords etc. However, due to the low-entropy of passwords, the encryption is inherently weak -anyone with access to the ciphertext can easily uncover the key (and hence disclose the plaintext). Mozilla used to have a very similar sync solution in Firefox 3.5, but since Firefox 4 it has made a complete change of how sync works in the browser. The new solution is based on a security protocol called J-PAKE, which is a balanced Password Authenticated Key Exchange (PAKE) protocol. To our best knowledge, this is the first large-scale deployment of the PAKE technology. Since PAKE does not require a PKI, it has compelling advantages than PKI-based schemes such as SSL/TLS in many applications. However, in the past decade, deploying PAKE has been greatly hampered by the patent and other issues. With the rise of patent-free solutions such as J-PAKE and also that the EKE patent will soon expire in October, 2011, we believe the PAKE technology will be more widely adopted in the near future. About the authors Feng Hao is a Lecturer of CSR. He received his BEng (2001) and MEng (2003) in electrical and electronic engineering from Nanyang Technological University, Singapore, and a Ph.D (2007) in computer science from the University of Cambridge, England. His research interests include biometrics, cryptography, fuzzy search algorithms, information coding, and error correction codes. Peter Ryan is a Professor of the University of Luxembourg. He is responsible for the security and privacy aspects of the DIRC program and is involved in the European MAFTIA project. He conducted research in formal methods and information assurance at GCHQ, CESG, DERA, SRI Cambridge, the Norwegian Computing Centre Oslo and the Software Engineering Institute, Carnegie Mellon University. Before migrating into information assurance he was a theoretical physicist and holds a BSc in Theoretical Physics and a PhD in Mathematical Physics from the University of London for research in quantum gravity. He has published numerous articles; the most recent being "Mathematical Models of Computer Security," a chapter in LNCS 2171, is based on lectures given at the FOSAD 2000 Summer School. He is co-author of the book "Modelling and Analysis of Security Protocols," Pearson 2001. Recently he has been active in the area of cryptographic voting schemes, in particular developing the Pret a Voter scheme. He has co-chaired several worskhops in this area, notably WOTe 2006: http://www.wote2006.org/ Suggested keywords SECURE SYNC DROPBOX FIREFOX SYNC CHROME SYNC How To Syn with Ali e Feng Hao1 and Peter Y.A. Ryan⋆2 1 S hool of Computing S ien e New astle University feng.hao n l.a .uk 2 Fa ulty of S ien e University of Luxembourg peter.ryan uni.lu Abstra t. This paper explains the syn problem and ompares solutions in Firefox 4 and Chrome 10. The syn problem studies how to se urely syn hronize data a ross di erent omputers. Google has added a built-in syn fun tion in Chrome 10, whi h uses a user-de ned password to en rypt bookmarks, history, a hed passwords et . However, due to the low-entropy of passwords, the en ryption is inherently weak anyone with a ess to the iphertext an easily un over the key (and hen e dis lose the plaintext). Mozilla used to have a very similar syn solution in Firefox 3.5, but sin e Firefox 4 it has made a omplete hange of how syn works in the browser. The new solution is based on a se urity proto ol alled J-PAKE, whi h is a balan ed Password Authenti ated Key Ex hange (PAKE) proto ol. To our best knowledge, this is the rst large-s ale deployment of the PAKE te hnology. Sin e PAKE does not require a PKI, it has ompelling advantages than PKI-based s hemes su h as SSL/TLS in many appli ations. However, in the past de ade, deploying PAKE has been greatly hampered by the patent and other issues. With the rise of patent-free solutions su h as J-PAKE and also that the EKE patent will soon expire in O tober, 2011, we believe the PAKE te hnology will be more widely adopted in the near future. 1 Introdu tion The past two de ades have seen the gradual evolution of a omputer. A omputer used to be a luxury, but now it is a ne essity; it used to be bulky and xed at one lo ation, but with the rise of smartphones and tablets, it is be oming smaller and more mobile; it used to store data lo ally, but now data storage is moving to the loud (whi h an be a essed anywhere from the Internet). One trend from this evolution is that an individual now tends to own several omputing devi es. At home, he may use a good-performan e desktop PC for entertainment; on the road, he may use a smart phone to read news and he k emails; at meetings, he may use a laptop or a tablet to deliver a presentation. The possession of multiple omputers naturally raises a pra ti al problem: how to keep data in syn a ross di erent platforms? ⋆ Sponsored in part by the FNR Luxembourg Dropbox o ers a popular solution. A ording to the report, it has a population of 25 million users worldwide [3℄. To set up a syn a ount, the user needs to provide a username/password. On e installed, the software will entrally store the user's les on the ompany's servers, automati ally tra ks the hanges, and syn hronizes the hanges a ross the user's omputers. The syn pro ess happens in the ba kground and is transparent to users. However, there is a serious la k of priva y prote tion in the Dropbox solution. As Dropbox states its se urity poli y on its website [3℄, Dropbox employees are prohibited from viewing the ontent of les you store in your Dropbox a ount, and are only permitted to view le metadata (e.g., le names and lo ations). Meanwhile, the ompany also a knowledges: there are a small number of employees who must be able to a ess the les whenever ne essary. Although this is stated by the ompany poli y as rare ex eption, not the rule , the se urity is hardly reassuring. (If an insider atta ker leaks users' personal les to the government, the users will probably never know.) Browser vendors fa e exa tly the same problem. Every browser keeps a user pro le, whi h in ludes history, bookmarks, a hed passwords and so on. The user pro le used to be stored lo ally, but it has be ome in reasingly ne essary to store it remotely (in a loud ), and syn hronize the pro le a ross the user's omputers. This an signi antly improve the usability and produ tivity. For example, if a user buys a brand new laptop, after syn he will be able to instantly re-use the same bookmarks, history et that were previously a umulated on another laptop. This is quite onvenient. As browser vendors re ognize, se urity is a key issue. The user pro le ontains se urity-sensitive information for example, it may ontain passwords for online banking or other a ounts. If the data is stored on the vendor's loud and the vendor an read data, users must ompletely trust the vendor (just as in Dropbox) not to misuse it. But, the problem goes deeper than the mere trust. If the vendor has ready a ess to all the user's on-line a ount passwords in the loud, what are the legal impli ations if the user a ounts are ompromised? How an the vendor establishes the publi on den e that it did not leak any user's passwords nor misuse them? The right solution seems to have an end-to-end en ryption between the two syn omputers. All data between the omputers is en rypted. The user is the sole holder of his own en ryption key; no one else is able to read data not even the loud provider. Both Mozilla Firefox and Google Chrome aim to provide su h a solution. In the following se tions, we explain their solutions in detail. The same syn design in the browser is instrumental and an be generally applied to many other appli ations (e.g., to address the se urity loophole in Dropbox). 2 Ba kground In this se tion, we brie y explain the Password Authenti ated Key Ex hange (PAKE) te hnology in general and the J-PAKE proto ol in parti ular. They are relevant to solving the syn problem. 2.1 Password Authenti ated Key Ex hange Password Authenti ated Key Ex hange (PAKE) is a foundational building blo k for a wide range of se urity appli ations. This te hnique allows establishing seure ommuni ation between two parties solely based on a shared password without requiring a Publi Key Infrastru ture (PKI). A PAKE proto ol shall ful ll the following se urity requirements: 1. O -line di tionary atta k resistan e It does not leak any information that allows a passive/a tive atta ker to perform o -line exhaustive sear h of the password. 2. Forward se re y It produ es session keys that remain se ure even when the password is later dis losed. 3. Known-session se urity It prevents a dis losed session from a e ting the se urity of other established session keys. 4. On-line di tionary atta k resistan e It limits an a tive atta ker to test only one password per proto ol exe ution. A se ure PAKE proto ol has several ompelling advantages over PKI-based s hemes su h as SSL/TLS. First, it does not require a PKI, whi h is parti ularly expensive to set up and to maintain. Se ond, it allows zero-knowledge veri ation of a password: in other words, the user an prove to the other party the knowledge of a shared password without revealing it. Sin e the password is never dis losed to the other party (unlike in HTTPS), a PAKE proto ol is naturally resistant to phishing atta ks. The rst PAKE proto ol was alled the En rypted Key Ex hange (EKE), designed by Bellovin and Merrit in 1992 [5℄. Subsequently in 1996, Jablon proposed another solution alled Simple Password Exponential Key Ex hange (SPEKE) [7℄. Many other PAKE proto ols were proposed. In 2000, IEEE P1363.2 formed a working group to study all available PAKE proto ols and to sele t se ure ones for standardization. However, in 2008, the proje t ran out of the maximum eight years; no on rete on lusion seemed to be made. Two hurdles emerged during the standardization pro ess. First, patent was a big issue. Many PAKE proto ols were patented. In parti ular, EKE was patented by Lu ent Te hnologies [6℄, SPEKE by Phoenix Te hnologies [8℄, and SRP by Stanford University [4℄. Se ond, these proto ols were found vulnerable. EKE was reported to leak partial information about the password, hen e failing to satisfy the rst requirement [9℄. SPEKE was found to allow an a tive atta ker to test multiple passwords in one proto ol exe ution, therefore it does not fulll the fourth requirement [11℄. Similarly, the SRP does not satisfy the fourth requirement, as explained in [12℄. None of these proto ols have se urity proofs. 2.2 J-PAKE It be ame lear in 2008 that the PAKE problem was still unsolved. In the same year, Hao and Ryan proposed a new PAKE proto ol, alled Password Authenti ated Key Ex hange by Juggling (J-PAKE) [1,2℄. The proto ol follows a ompletely di erent approa h from past s hemes. It works as follows. Let G denote a subgroup of Z∗ p with prime order q, and g be a generator in G. Let s be a shared password between Ali e and Bob, and s 6= 0 for any non-empty password. The value of s is assumed to be within [1, q− 1]. Ali e sele ts two se rets at random: x1 ∈R [0, q − 1] and x2 ∈R [1, q − 1]. Similarly, Bob sele ts x3 ∈R [0, q − 1] and x4 ∈R [1, q − 1]. Round 1 Ali e sends out g1 , g2 and knowledge proofs for x1 and x2. Similarly, Bob sends out g3 , g4 and knowledge proofs for x3 and x4. The above ommuni ation an be ompleted in one round as neither party depends on the other. When this round nishes, Ali e and Bob verify the re eived knowledge proofs, and also he k g2 , g4 6= 1. Round 2 Ali e sends out A = g1342 and a knowledge proof for x2 · s. Similarly, Bob sends out B = g1234 and a knowledge proof for x4 · s. When this round nishes, Ali e omputesK = (B/g24)2 = g(x1+x3)·x2·x4·s, and Bob omputes K = (A/g24)4 = g(x1+x3)·x2·x4·s. With the same keying material K, a session key an be derived κ = H(K), where H is a hash fun tion. Ali e and Bob will subsequently perform expli it key on rmation as des ribed in [1℄. In the proto ol, the knowledge proof an be realized by using, for example, S hnorr signature. Overall, the J-PAKE proto ol has been proved to ful ll all the four se urity requirements. In addition, the proto ol is unpatented. The J-PAKE proto ol and se urity proofs have been available on the IEEE P1363.2 website3 for publi review for over three years; no atta ks have been found. 3 Syn solutions in Browsers In this se tion, we will explain how major browser vendors try to ta kle the syn problem. In parti ular, Firefox 4 presents an interesting ase study as it is the rst browser to adopt the PAKE te hnology in the syn design. 3.1 Overview Syn has be ome an important feature for a modern browser. With the ex eption of IE 9, new releases of browsers generally have built-in support for syn (see Table 1). In the following se tions, we will fo us on omparing syn in Firefox 4 and Chrome 10, as their solutions are representative. 3.2 Chrome syn Chrome 10 provides a straightforward syn design, based on using a password as the en ryption key. Setting up syn in Chrome 10 is almost zero e ort as long as you have an Gmail a ount. The user an then on gure what to syn . By 3 http://grouper.ieee.org/groups/1363/Resear h/ ontributions/hao-ryan-2008.pdf Browser Release date Built-in Syn -key Pri e Firefox 4 Mar, 2011 Yes 128-bit Free Chrome 10 Mar, 2011 Yes Password Free IE 9 Mar, 2011 No Opera 11 De , 2010 Yes None Free Safari 5 Jun, 2010 Yes None $99 per year Table 1. Overview of Syn solutions in browsers default, that is everything: apps, autoll, bookmarks, extensions, preferen es, themes and passwords (Figure 1). The browser o ers two options to en rypt the syn data: re-using the Gmail password (default) or hoosing a new password (Figure 2). Fig. 1. Confgure syn in Chrome 10 However, Google's solution provides virtually no guarantee of priva y. In both options, the en ryption key is dire tly derived from a password. Due to the human's inability to remember ryptographi ally strong se rets, a password normally only has 20-30 bits entropy. Thus, although Google en rypts the syn data in its loud, the en ryption key is inherently weak. Anyone who has a ess to the iphertext an readily break the key by exhaustive sear h and fully un over the syn data. Fig. 2. En ryption options in Chrome 10 syn 3.3 Firefox syn The previous version of Firefox (3.5) used to have a similar syn solution. To set up syn , the user needed to remember two passwords: one for the syn a ount, and the other for en rypting data. The en ryption works basi ally the same as in Chrome 10 using a user-de ned password as the en ryption key. One subtle di eren e is that in Chrome 10, the default option is to re-use the Gmail password as the key, while in Firefox 3.5, the default is to let the user de ne a new password. Be ause the en ryption was inherently weak, Firefox 3.5 had the same problem as in Chrome 10. Similar to Google, Mozilla was at a privileged position: it was able to read all the user's data despite that the data was en rypted (by a password). In re ognition of this problem, the ompany has been trying to nd a solution. From Firefox 4 beta 8 (released in De , 2010), Mozilla made a omplete hange in the syn me hanism. The new solution adopts the Password Authenti ated Key Ex hange te hnology in parti ular, it hose J-PAKE. Figure 3 shows an overall diagram about how syn works in Firefox 4. First, the browser generates a random 128-bit key, alled the syn -key. This syn -key is never sent to Mozilla. It is used to en rypt the browser bookmarks, history, a hed passwords et . Only the en rypted data is stored at the Mozilla loud . Alternative servers an be used, and one an even set up his own server. To set up syn in Firefox 4 is relatively straightforward. First, one needs to on gure what data to syn (see Figure 4). Se ond, the J-PAKE algorithm is used